Many enterprise data processing systems rely on multi-node database servers to store and manage data. Such enterprise data processing systems typically follow a multi-tier model that has a multi-node database server in the first tier, and one or more computers in the middle tier and outer tiers.
FIG. 1 depicts multi-node database server mds11, which is implemented on multi-tier architecture 10. A server, such as multi-node database server mds11, is a combination of integrated software components and an allocation of computational resources, such as memory, a node, and processes on the node for executing the integrated software components on a processor, the combination of the software and computational resources being dedicated to performing a particular function on behalf of one or more clients. Resources from multiple nodes in a multi-node computer system can be allocated to run a particular server's software. A particular combination of the software on a node and the allocation of the resources from the node is a server that is referred to herein as a server instance or instance. Thus, a multi-node server comprises multiple server instances that can run on multiple nodes. Several instances of a multi-node server can even run on the same node.
A database server governs and facilitates access to a particular database, processing requests by clients to access the database. A multi-node database server, such as multi-node database server mds11, comprises multiple “database instances”, each database instance running on a node. Multi-node database server mds11 governs access to database db11. A multi-node database server can govern and facilitate access to one or more databases.
The middle-tier of multi-tier architecture 10 includes middle-tier computer cmp11 and the outer-tier includes user computer cmp12. User computer cmp12 executes browser br11, which interacts with an end-user. The end-user's interaction with browser br11 causes the browser to transmit requests over a network, such as the Internet, to middle-tier computer cmp11. The request causes a process on middle-tier computer cmp11, client c11, to execute application appl11. Execution of application appl11 by the client c11 causes client c11 to connect to multi-node database server mds11. For example, application appl11 may be an order entry application that is configured to receive order requests from browser br11. Data for the order entry application is stored in db11. To process the requests, execution of application appl11 by client c11 causes client c11 to connect to database db11. Once connected, client c11 issues database statements to retrieve and manipulate data stored in database db11.
The tier that directly connects to a server, relative to other tiers in a multi-tier architecture, is referred to herein as containing the client of the server. Thus, client process c11 is referred to herein as the client of multi-node database server mds11.
An application, as the term is used herein, is a unit of software that is configured to interact with and use the functions of a server. In general, applications are comprised of integrated functions and software modules (e.g. programs comprised of machine executable code or interpretable code, dynamically linked libraries) that perform a set of related functions.
An application, such application appl11, interacts with a multi-node database server mds11 via client-side interface component intcomp11. Execution of application appl11 causes client c11 to execute client-side interface component intcomp11 to interact with multi-node database server mds11. Application appl11 includes invocations of routines (e.g. functions, procedures, object methods, remote procedures) of client-side interface component intcomp11. Applications are typically developed by vendors and development teams different from those that develop servers and interfaces to servers, such as multi-node database server mds11 and client-side component intcomp11.
In order for a client to interact with multi-node database server mds11, a session is established for the client on a database instance of multi-node database server mds11. A session, such as a database session, is a particular connection established for a client to a server, such as a database instance, through which the client issues a series of requests (e.g., requests for execution of database statements).
For each database session established on a database instance, session state is maintained for the session. Session state includes the data stored for a database session for the duration of the database session. Such data includes, for example, the identity of the client for which the session is established, and temporary variable values generated by processes and database components executing software within the database session. A database component is a set of software modules that provide specialized and related functions for a database server, and shall be described later in greater detail. An example of a database component is a Java execution engine.
The beginning and end of a session demarcates a unit of work. Often, the beginning of a database session corresponds to an end-user establishing an interactive session with an application via, for example, a browser, and ends when the end-user logs off. Thus, the beginning and ending of the database session depend on application logic and end-user action, and may not be controlled by a server on which the session is established.
Client-Side Interface Components
Client-side interface components, such as client-side interface component intcomp11, are software components that reside and are executed on the same computer of a client of a server, and that are configured to provide an interface between the client and the server. The client-side interface component intcomp11 is configured for performing the detailed operations needed to interface with multi-node database server mds11. For example, an application appl11 invokes a function of client-side interface component intcomp11 to establish a connection to multi-node database server mds11. The client-side interface component then handles the details of a connection on a particular instance of multi-node database server mds11. To make requests of multi-node database server mds11, such as a request for execution of a query, application appl11 is configured to invoke functions of client-side interface component intcomp11, which then transmits a request for the same to the node and database instance on which the session is established.
Client-side interface component intcomp11 may generate and/or access state that is hidden from other software modules, that is, is not or may not be referenced and accessed by other software modules, and in particular, by application appl11. Such state is referred to as being internal or private to client-side interface component intcomp11.
For example, to create a database session on a multi-node database server mds11, application appl11 invokes a routine of client-side interface component intcomp11. The client-side interface component establishes a database session on a particular database instance within multi-node database server mds11, and stores details about the database session within internal data structures or objects. Such data structures and objects define, for example, the session established for an application, and specify such values as an identity of a session on a database instance, the name of the database instance, and a network address and port number for the connection to the database instance.
Such details of the session are not returned to application appl11, nor may application appl11 access the details. Instead, what is provided to application appl11 is an “external identifier” for the session, such as a value that internal data of client-side interface component intcomp11 maps to the session, or a reference to an object generated by client-side interface component intcomp11 to store some details of the session in private attributes of the object that are inaccessible to application appl11. In this way, application appl11 does not “know” of the specific details of the session that has been established for it; however, application appl11 has the information needed to be able to identify to client-side interface component intcomp11 the particular session that has been established for application appl11.
Distributing Workload
An important capability needed to manage multi-node database servers is to distribute work load between the nodes. Distributing work load is used to improve performance, by optimally balancing workload between nodes. Distributing workload also allows work to be shifted from a node that is being taken off-line for maintenance operations to another node.
To improve performance, work load on a multi-node database server is distributed using connection-time balancing. Under connection-time balancing, work load is distributed at connection-time, when a database session for a client is created. Specifically, when a client requests to establish a database session on a multi-node database server, the session is placed on an instance or node based on work load considerations. For example, a client transmits a request for a session to a multi-node database server. The multi-node database server determines that a node is less busy than other nodes, and establishes a session for the client on that node.
A drawback to connection-time balancing is that it cannot rebalance existing sessions; it only balances sessions when they created. The work load created by existing sessions cannot be shifted and does not abate until a client, on its own accord, reduces or ceases to make requests and/or terminates the sessions. As a result, the timing of work load shifting is subject to events not under the control of a multi-node database server.
Based on the foregoing, it is clearly desirable to provide a way to shift work load of clients of sessions after the sessions have been created.